According to the National Institute of Standards and Technology (NIST), “cloud computing” is defined as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” One of the characteristics of the cloud model is resource pooling, which allows computing resources to be pooled to serve multiple customers using a multi-tenant model. Physical and virtual resources can then be dynamically assigned and re-assigned according to customer demand. Because of these and other benefits, many organizations are moving their applications to the cloud. The cloud model can be deployed in the form of a private cloud, a community cloud, a public cloud or a hybrid cloud. According to NIST, a private cloud is a cloud infrastructure provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). The private cloud may be owned, managed, and operated by the organization, a third party, or some combination thereof, and it may exist on or off premises. As used herein, a “cloud provider” is a service provider that offers customers storage and/or software (e.g., application) services available via a cloud, which may be private, public, community, or hybrid cloud.
For any non-trivial application, it is highly desirable to formally define its resource (e.g., compute, database (DB), messaging, storage, etc.) requirements in a given environment. It is even more critical in a cloud environment, which deploys a large number of applications, to have concise resource requirements because the resources requirements are tightly coupled with managing the inventory, utilization, cost and more importantly managing risk associated with not having the resource when needed. For example, consider an organization that has thousands of applications which utilize hundreds of thousands of resources deployed in a cloud environment. If the resource requirements for every application are known and the proper utilization of the resources after the resources were allocated to a given application can be validated, the organization would be able to, for example, efficiently manage its inventory and application workloads to achieve optimal utilization of the resources.
Customers can typically specify the resource requirements of an application in a given environment by specifying the resource itself, and the placement requirements. For example, in case of “compute” resource, cloud providers allow customers to define a number of cores, memory, storage, etc., what software should run on a virtual machine (VM), how to configure a VM, and/or the like, as well as which datacenter or region the “compute” resource would live on. However, there are several limitations in the existing mechanism for specifying the resource requirements of an application. For example, the existing mechanism describes the resource requirements from cloud provider perspective, and not the customer or application perspective. Consequently, a typical resource specification is often tightly coupled to the cloud provider's infrastructure, which makes changing cloud providers difficult. By way of another example, the existing mechanism acts on the resources individually. In other words, the existing mechanism puts an absolute requirement (cloud provider specific) on the resource, which can cause problems in fulfilling a resource specification. For example, if the resource specification specifies that a “compute” resource be placed in datacenter “BDC,” and if the datacenter “BDC” has no capacity, then the resource specification will not be fulfilled.
The present disclosure overcomes these and other limitations of existing mechanism for capturing and communicating resource specification, and provides other benefits as will become clearer to those skilled in the art from the foregoing description.